This invention relates generally to computer systems, and more particularly to a mechanism for enabling session information to be shared across multiple processes.
On the Internet or World Wide Web, information is generally communicated on a request-response basis. That is, a client (typically running a browser program) submits a service request to a server. The service request may simply ask for a static page (usually in HTML format), or it may request that a particular application or program be executed to generate a return page. In response to the service request, the server performs whatever tasks are necessary to service the request, and provides a response page to the client. This request-response sequence, referred to as a “roundtrip”, is carried out for each request.
For simple applications in which every task that needs to be performed can be carried out single roundtrip, statelessness is not a problem. However, for exchanges (such as transactions) that require multiple roundtrips, the lack of state presents a significant impediment.
An example of an application in which it is necessary to maintain state across multiple roundtrips is that of an “electronic shopping cart” application. More specifically, a user visits a merchant's website using a particular client machine. As the user peruses the website, he sees an item that he wishes to purchase, and puts that item into his “shopping cart”. As some point, the user invokes a link to another page of the website, and at that point, a request is sent to the server which requests the desired page and which also provides to the server all of the items currently in the shopping cart. The server responds to the request by storing information pertaining to the shopping cart items, and by providing the desired page to the client. Thereafter, the user peruses the new page and puts additional items into the shopping cart. In a subsequent request by the client, the additional items in the shopping are sent to the server. Since the subsequent request is from the same client, the server should associate the additional items with the previous items as being in the same shopping cart. To do this, though, the server needs to associate the subsequent request with the previous request, which in turn requires that the server maintain state information relating to the requests. However, as noted above, the Internet is generally a stateless environment. As a result, without further functionality on the part of the server, multiple roundtrip exchanges, such as those required by the electronic shopping cart application, cannot be implemented on the Internet.
To enable exchanges involving multiple roundtrips to be carried out, some servers implement session management functionality. Basically, this functionality maintains session information across multiple roundtrips so that associations between multiple requests can be made. As used herein, the term session information refers broadly to any information, including state information, which can be used to relate one request with another request. Usually, state information is maintained by passing session ID information back and forth between the client and the server. For example, when a service on the server requiring state information is first invoked by a client request, a new session is created, and a new session ID is associated with the new session. The session acts as a “container” to store all of the necessary state information relating to that particular session. Once the session is created (and possibly updated to include state information relating to processing of the current request), the associated session ID is provided to the client that requested the service. If that client makes a subsequent request to the same service, the client includes in that request the session ID. Using the session ID, the server accesses the associated session, and based upon the state information stored in the associated session, the server can determine what has transpired thus far. In this manner, the server is able to associate a current request with one or more previous requests.
Typically, the session management functionality of a server is process-specific. That is, each instance of the server (with each instance being its own process) maintains session information for its own sessions, and only that process can access and manipulate that session information. This is not a problem if there is only one instance of the server, or if it is guaranteed that the same server instance will service all of the requests pertaining to a particular session. However, where there are multiple instances of the server, and there are no guarantees that the same instance will receive all of the requests pertaining to a particular session, this process-specific limitation of the session management functionality can lead to serious errors.
To illustrate, suppose that there are two instances of a server (i.e. two server processes) running in a particular system, and that requests are distributed to these two server processes in a round-robin fashion. In such a system, it is quite possible for two requests pertaining to the same session to be processed by two different server processes. If that occurs, processing errors may and most likely will occur.
For example, suppose that the first request of a transaction is received and processed by a first server process. In response to this request, the first server process creates a new session, and assigns that new session a session ID. This session ID is returned to the client submitting the request. Suppose further that that same client submits a second request pertaining to the same session, and includes in the second request the session ID that was received from the first server process. Suppose, however, that this second request is received not by the first server process but by a second server process. Because the second server process cannot access the session information of the first server process, it cannot carry on processing of the transaction in the same manner as the first server process. Instead, the second server process may respond in one of several different ways. First, the second server process may simply not recognize the session ID, in which case, it creates a new session and a new session ID. If this occurs, then the same transaction will have two different sessions (one on each server process), with neither session containing all of the state information for the entire transaction. This clearly is not a desirable result. Worse yet, the second server process may recognize the session ID (but this session ID will be associated with another session completely unrelated to the transaction pertaining to the request), and use the state information in that session to service the request. If that occurs, not only will errors arise in servicing the current request, but the data for the other session will also be corrupted. As this discussion shows, the process-specific limitation of the session management functionality can lead to serious errors in a multi-process environment. As a result, an improved mechanism for implementing session management in a multi-process environment is needed.